Typically in data transmission over a network, a transmitter transmits certain size packets periodically and a receiver receives the transmitted packets and plays them. However, although the receiver transmits at fixed intervals, there is some variation in the time intervals at which transmitted packets are received by the receiver. For example, a transmitter may transmit a packet every 100 ms, so that at time 0, packet A is transmitted, at time 0+100, packet B is transmitted and at time 0+200, packet C is transmitted. The receiver, however, may receive packet A at time 0+10, packet B at time 0+110 (a 100 ms interval) and packet C at time 0+230 (a 120 ms interval).
The variation in the time intervals between which packets are received is called jitter. Jitter causes problems for real-time streaming data applications because proper data reproduction requires consistent playback timing. Streaming data transfer differs from other types of data transfer in that the data transferred has a temporal aspect. Once the receiver begins to reproduce the stream of data at the destination, it must continue to reproduce that data stream continuously according to the temporal structure of that data, or else the reproduction of that data will have lower quality. As an example, without limitation, audio data has this structure. A stream of audio data must be reproduced at the destination with the right temporal structure, or it will not sound correct to the listener. Therefore if a packet arrives late because of jitter, the receiver may not be able to play a continuous stream of data if the packet is not available when required to maintain consistent playback timing. The packet unavailability causes the playback to “break up” and reduces playback quality.
To compensate for playback errors, streaming data applications communicated over packet-based networks typically use a “jitter buffer” to implement a measure of delay before playback on the receiver. As the receiver receives packets, it does not play them back right away, but instead, copies them to a jitter buffer. The data stream is then played from the jitter buffer. If the size of the jitter buffer is larger than the amount of jitter present in the network, then the receiver will be able to play back a smooth and unbroken stream of data, because there will always be data available in the jitter buffer for playback.
The jitter buffer, however, adds latency to the playback. In the context of streaming data transmission and playback, latency is the time between input of data by the sender and rendering of that data by the receiver. The length of the jitter buffer increases latency. If the jitter buffer is 50 milliseconds (ms) in length, there may be up to 50 ms of delay attributable to the size of the jitter buffer in addition to any additional latency attributable to the network and other components of the communications system. Thus it is desirable to have the smallest jitter buffer that provides adequate playback quality.
The size of jitter buffer required to provide adequate playback quality will change as conditions change on the network between the transmitter and receiver. Thus it would be desirable to have a method to automatically adjust the size of the jitter buffer, thus adjusting the length of delay of playback, in response to changing network conditions.